Like most technology, as cloud computing has matured over the past decade, it has become considerably more complex.

On the plus side, the inherently complicated nature of cloud has created numerous opportunities for startups and large incumbents alike to create new services and standalone businesses. HashiCorp was one of the earliest companies to identify the multiple entry points in the cloud ecosystem.

Founded in 2012, HashiCorp is an provider of products that are foundational to mission-critical cloud applications and infrastructure. As such, the company has become an essential partner to numerous organizations ranging from startups to the Big 3 cloud providers. It is both a competitor and a collaborator, and is perhaps the best representation of the open-source, multi-cloud paradigm in which almost all companies now operate.

As we discussed in the most recent Castles in the Cloud funding analysis, HashiCorp’s public market debut in late 2021 represented not only a milestone for the cloud sector overall, but the growing reality that functioning in today’s ecosystem requires a multi-cloud approach.

HashiCorp CEO Dave McJannet joined me on the Greymatter podcast to discuss the current cloud landscape, how the company continually innovates to keep up with the increasing complexity of the cloud ecosystem, and the new opportunities for startups.

You can listen to the conversation at the link below or wherever you get your podcasts.

Jerry Chen: Hi everyone. Welcome to Greymatter, the podcast from Greylock where we share stories about company builders and business leaders. I’m Jerry Chen, general partner in Greylock, and today my guest is David McJannet, CEO of HashiCorp.

HashiCorp is one of the defining companies in the cloud and we’re super excited to have David today. Hashi was started in 2012 and went public last year. And it’s been one of the category-defining cloud infrastructure, cloud open source companies.

I’ve had the privilege to work with David for many years. So Dave and I worked together first at VMware over 10 years ago, and then he was briefly at EIR at Greylock.

So Hey David, thank you for coming on the podcast today.

David McJannet: Thanks for having me. Yeah, it has been 10 years shockingly, but probably slightly more.

JC: It’s been 10 years and obviously the news a couple weeks ago of VMware Broadcom acquisition, I want to talk about all things cloud.

But first, maybe [we’ll] just riff about our times there, and Cloud Foundry/vFabric is how you and I first came to work together, where we tried to build this first effort around cross cloud multi-cloud software. What do you think we got right back then, and what do you think we got wrong?

DM: To me there’s such a consistent pattern to this stuff of existing spend categories transitioning from old world to new world. And essentially what Cloud Foundry was, was a bet that the app server market, (basically how people were going to run and deploy applications) was going from a world of WebLogic, WebSphere, maybe Tomcat to a world of this highly curated runtime platform, which at that time we were just messing around the wording web as a platform-as-a-service.

And so that turns out, the platform-as-a-service notion is just a modern version of an app server and I think we got that right. I think we also got the idea right that developers just want to be able to do a CF push rather than declare all the infrastructure that underpins that application, they just want to push that application element.

I think that part got right, and Cloud Foundry then became a thing. In fact, we were joking about how that got started. It’s actually amazingly simple how these things you get ideated become these things. And I remember the picture on the whiteboard of what ultimately became Cloud Foundry got propagated around the internet. I think you got the design from 99 designs or something similar. It was not very complicated how it all got started, but it turned out to be pretty right.

JC: Best $99 we spent back then.

So maybe we’ll segue that to this journey to HashiCorp. You did a brief stint at a couple of the companies before landing at Greylock as EIR. We’re going to get in the weeds around cloud and open source and HashiCorp, but for those that listen to podcasts that may be less familiar about, deep, deep infrastructure technology, tell me a little bit about HashiCorp, what are the products you sell and how do they work together?

DM: Sure. So of course the thesis was that the infrastructure transition underway is from people running private data centers to people running cloud, which is just a different operating model with very different paradigms for the core aspects of infrastructure. And so we provide a suite of products that address the challenges of running and securing apps in distributed systems i.e. outside of the data center.

We took a very Unix view of the world which is, “Let’s create one product that does one thing and then another product that does another thing, and you can use them together.”

Originally, the team said, “I think there are actually four problems that we need to solve to run cloud infrastructure so let’s try and solve all four of them.” And one’s around infrastructure provisioning.” Well, that became [our product] Terraform, one’s around the identity based security of things in the cloud – “Can this thing talk to this thing? I don’t know what its identity [is].”

That’s the core paradigm of security in the cloud; it’s identity-based and that is [our product] Vault.

Then the question becomes, “How do I network it all together? This thing wants to talk to this thing. Is it allowed to?”

Well, Vault tells me that, but the actual connection of it is what Console does. So it’s a modern take on networking. And then the fourth problem to solve is, “How do I then run compute jobs across that distributed fleet?

So those four problems – – basically infrastructure, security, networking, and then the run time are the four problems that have to get solved in cloud. And so ergo the Hashi stack was born. So these were actually independent products that were created but you generally use them together.

So today we see companies that run a 20,000 server estate. They run these products to underpin them all and it basically acts as one throbbing, humming, distributed compute fabric with nomad scheduling jobs across the top. So, it’s pretty complex distributed system stuff, but it decomposes into four core products that underpin it.

JC: Yeah. Those four core things – identity, security, networking, infrastructure – you and I have riffed on, and have been the core paradigm from the first mainframe to the mini computer, to the PC, to the cloud that you always need compute. You always need networking, you always need identity, you always need infrastructure. And what happens is, every time it’s with this platform shift, these elements get rehydrated into different technologies.

But to your point, I think the genius of HashiCorp was, one, you identify these are the, call it atomic elements or the stem cells of the cloud that can either work independently, and some of your customers do, but also work together as a stack because the evolution to this cloud comes at different paces, different rates for different customers. And so your ability to have customers either start with Vault or start with Console or start with Terraform and then evolve over time, embracing all four parts is super interesting. I think that’s one of the things you guys got right that we didn’t get right at Cloud Foundry for example.

DM: Exactly. I think all platform tech, again in hindsight, gets adopted the same way. It’s about balancing insertion point versus big picture vision.

So what I just described, imagine, and this is literally what we see in our customers. If you’re playing a game or if you’re sending a message to your friend, or if you’re streaming a processing payment, it is going through our stuff. And what it’s doing is a basically federated fleet of thousands of servers that that customer’s running, and they put this stuff on top and it’s basically having a single computer look like across 1,000 different machines and then finding that open slots to drop in things where there’s processing space in a secure way and network, et cetera.

So that’s what it looks like at scale. That’s pretty sophisticated stuff but that’s not where most people start. It’s too big of a vision for them to get there to have 20,000 servers wired together like this.

So you have to determine an insertion point, which is why this Unix philosophy worked really, really well. How about you just start with the infrastructure provisioning problem. Let’s just start with that one. And I can walk you over the course of years into that broader picture vision once you’re ready for it. It’s just too big of a vision to sell it because it’s such a different paradigm. Cloud Foundry conversely says, “Here’s your black box?” And people go, “Well, that’s an awfully big black box. What’s it doing?” And you go, “Don’t worry about it. It just works.” I said, “What happens when it doesn’t?” And so there’s just a lot of reluctance and it’s very hard to get a bottoms up adoption motion when I’m just telling you one big thing. Now people want to be able to adopt the elements and walk their way to it.

JC: Yeah. I think the insertion, or I keep preaching like, “The sharpness of the wedge is what matters,” right? It’s the pointy tip of the spear or the sharper wedge. And oftentimes with startups, you want to have a very narrow wedge, you’ll land insert with low friction. You always want low friction in, high friction out, right? As a platform company or infrastructure company. And many startups fail because they see the second or third act where they want to be, but they forget that you don’t get to the third act if you don’t have a very good wedge to land on.

I think the nice thing, what you guys built at HashiCorp was this portfolio of three or four different wedges.One is historically an open source, especially in the cloud, especially with developers, and the history at HashiCorp is obviously tied with open source. And I’d love to hear about how HashiCorp thinks about open source, both [in terms of the] investment ecosystem, and then balancing that with a product you guys build and the business models around open source, be it enterprise version you sell versus a cloud-hosted version.

DM: I’m a disciple of the view that you can’t build an infrastructure company today that isn’t’ open source. That’s just my particular view. I think VMware was the last one. It was built at a time where open source really wasn’t a thing. I just think it’s hard to build an infrastructure company today that isn’t open source because so many people rely on it and they need it to be open source in many respects.

So our view was always that the products were going to be open source and we authentically committed to that. And I think that the approach you take is you say, “All right, what’s the role of open source?” There’s a development role and there’s a distribution role. On the development side, how can we construct a project where we can invite people to collaborate with us, to aggregate more people to build things that we wouldn’t otherwise build while retaining control of the direction of the project?

There’s a science and an art to that. Short version is, it comes to the architecture of those projects.

For example, you’ll notice Terraform, there’s Terraform core, and then there’s the provider ecosystem for what plugs into it. There are thousands of contributors to the providers. There are very few people that contribute to core and that’s the way the model works well for everybody.

So number one, it’s about getting development leverage and that’s one path. The second part is, how do you drive standardization? That’s really what you’re trying to achieve because you get distribution to end practitioners through open source, there’s no friction to the consumption of it, but you also get ecosystem standardization.

So the real magic of something like Terraform today is that there are thousands of Terraform providers. So if you want to use Terraform to provision something, you know there’s a Terraform provider for it, whether it’s for provisioning stuff on Amazon or whether it’s for configuring your GitHub account. Why? Because someone has built a provider for it. And actually it’s the standardization that you’re trying to accomplish with open source. That is just why would someone build a plugin for vSphere or a driver for vSphere, you wouldn’t until all of your customers required it, but in this way you can actually activate the ecosystem around it. So actually you have to authentically commit to that saying, “I’m not trying to make money out of that. I’m genuinely just trying to drive standardization because I think it’s good for everybody.”

I think that’s point number two, point number one is using it for development. Point number two is actually authentically committing to that idea that we’re not trying to monetize that group. We think it’s good for everybody after standardization. Then number three is about what’s your commercial model.

And I actually loved the comment that Mitchell [Hashimoto] made years ago because we realized early on that if you build a really big open source ecosystem in our community and then try to monetize that community, you have to reconcile that you’ve now aggregated a community of people with the predilection not to pay you anything. And I think there’s a truth to that. So you don’t try and monetize them. What you try to do is try to come up with a model that monetizes the usage of those products inside an enterprise, inside some other mechanism, but you’re not trying to monetize to some people. What we did is we had the philosophy of, “Hey, let’s say everything the practitioner needs is open source. We don’t hold that back.”

But everything the organization needs, so go sell that to the organizations that are using this tech. And you think about that paradigm, it’s actually just a different set of problems. You go from an individual to a team, to an organization as you could to get further organizational complexity, right? The team problem is one of collaboration. How do we collaborate around this thing? Okay. That’s an opportunity.

Number two is policy and governance for the organization: who can do what? Who did what? Audit trails and all the rest. So that’s how we think about it. So the commercial value is around that latter part. For most successful open source companies, it’s monetizing the organizational complexity, and I think that’s pretty straightforward to the users. It’s pretty honest and straightforward.

Now, do you do that in the form of a managed product, or do you do that in the form of an open core product? I think everybody’s preference is in the form of a managed product – Let me have my cloud service for Kafka, or Confluence, or pick technology A, B, or C. But I think you have to reconcile what your buyers want first.

So it turns out people’s appetite for consuming a managed database is actually pretty high because it’s only one app using that database. At the infrastructure area, it’s just a different beast. A vault goes down, the lights go off for all of your company, not just one application. So as a result, the bar is just much, much higher to consume that as a service. Turns out the market will tell you whether it wants to consume products as a service. In our case, it didn’t want to early on, they wanted us to have a self-managed version that they could manage themselves in enterprise form. I’ll maybe stop there because I could talk about this forever.

JC: No, no. I think you said two or three threads are super fascinating and it’s probably Armon and Mitchell, the two co-founders [of HashiCorp] had that great insight of open sourcing all the service area that practitioner had cared about and really committing to that. And then I think you came in 2016, was it?

JC: 2016 as CEO and you had insight – where Armon and Mitchell had this great insight and understood the developer aesthetic, you had the great insight under the organizational requirements of the monetization that I think that the three of you made such a great team. Because that separation of the personas practitioner like the developer versus the organization and had different needs identifying the organization paid for it and what those features are and making sure you don’t open source those features versus what the practitioner cared about, open source those things.

DM: It’s kind of church and state. We actually refer to it as church and state, and those things can’t cross.

JC: I’m afraid to ask what’s religion and what’s government, which is church. I think we both know. I think clearly the practitioner is the religion and the organization is the government regulating it.

JC: Hey, in this cloud world, where increasingly, HashiCorp is a fast-growing cloud business. Confluent is a fast-growing cloud business. Mongo Atlas is a fast growing cloud business. Snowflake is not open source at all, 100% cloud business. I’m involved in companies like Docker that is open source, Rockset’s 100% cloud, Chronosphere’s open source but then all cloud. Do you need to be open source anymore to win in the cloud game at all? Yes or no?

DM: I think it’s harder to drive market standardization. It depends what your aspirations are. So again, these companies, they get married together and they are in fact very different. And I would posit that there’s a big difference between the application layers: databases, message queuing and middleware, or basically the run-time layer, as opposed to core infrastructure, which is security networking and the infrastructure itself.

So let’s talk about the top layer, which I’m referring to as the app infrastructure. You don’t have to standardize that entire market to build a business. Look at Snowflake, they’re one of multiple data warehouses. Look at Confluent, they’re one of multiple message queuing options I have. Look at Kubernetes, it’s one of many runtime platforms that are out there. And so I think in that instance, you actually don’t need to be open source, I don’t believe. At the core infrastructure layer, it turns out there’s only one way to do TCP.

There’s only one way to do firewalls. There’s only one way to do networking. It all works the same way, right? To win at the infrastructure layer you need standardization because I’m going to have a variety of applications, but I can’t have a different way of doing networking. So I think those need to be open source. And so the adoption path ends up being subtly different too.

I think there’s a nuance that really matters here, which is at the app infrastructure layers, the databases, et cetera, middleware, it’s very app-driven. So I have an app that I want to be built in Kubernetes. I have an app that I want to do message queuing in this modern way. I have a set of apps that I wanted to do data warehousing with versus the infrastructure sells for all your apps, right? So there’s a very different motion.

I say the appetite for consuming a cloud service that services a single app is okay, because if that service goes down that sucks, but my lights still stay on, versus at the infrastructure layer. There’s just a different risk tolerance.

JC: So the framework then becomes, to your point, how many other things do you touch, right? Or integrate, or depend upon it like an app; a single CRM app. Notably there’s been tries at open source CRM (Sugar CRM, et cetera), but it has never worked out the same as other layers. But the lower level and the stack (clearly like a Kubernetes or a Docker), the more open source you have to be.

DM: Yeah. The lower down you get, the more important it is.

JC: Let’s talk about the early days at Hashi: tell us about the foundational early customers that really help Hashi get its footing, get started, and help sharpen the sword if you will, to polish what the product became. I’m curious, what were the inception customers and how has that changed over time?

DM: Yeah. I go back to the thesis for business building, which, in my view, is very consistent. It’s about old world/ new world transitions, architecturally that create the opportunity.

So what was happening 10 years ago was the emergence of cloud as a target. And it was the realization, “You know what? The paradigms are just different.”

I’ll take security as an example. Old world, the idea of four walls and a pipe in or pipe out and a firewall around it was how we think about security. Cloud world: wait a second. There’s no walls. It’s a setting on my S3 bucket. Is it inside or is it outside? This changes my world a little bit.”

And so the definitive conviction around, “Hey, the right way to do security and cloud is based on brokering identity.” That was the insight that Armon and Mitchell had early on. And they were just convicted around that. And they said, “Hey, this IP base where security makes no sense, let’s build a product that does identity based.” And then the people that were starting to use cloud were like, “Yeah, these guys are right. That’s right.”

And they started using it. So the people that were adopting that cloud paradigm first came to the realization that this was the right way to do it and those were the cloud-native companies. It’s the Twitches of the world. It’s the GitHubs of the world. It’s the early cloud-native folks that you would expect who were building companies at that time.

And that is where the initial traction came from, unquestionably, because we’d been very opinionated about the idea of “Infrastructure is code, how you do provisioning, identity is how you do security, service name is the way you do networking.”

Those three principles are the most profound. They’re just totally different principles. Once that got some adoption, you worked the edges off inside these big web cloud data companies and some of them are just absolutely enormous as you can imagine. Like, the scale of usage started to shock us, when all of a sudden you’re connecting 100,000 machines and you’re like, “Wait, I never expected that to happen.”

So that by the time some of the forward-leaning enterprises who we wanted to monetize ultimately started consuming this stuff as well, because they were like, “Hey, we’re building a massive web app that needs to be built on cloud infrastructure.” The very, very earliest of Amazon’s customers. They adopted it. And I think that’s actually quite repeatable, but it was related to this paradigm shift. You got to look for those. Who are the people that are looking at that new paradigm first, and it’s select financial institutions.

JC: We like to say some of those companies that you mentioned (the early adopters) have seen the future, right? So you look at some of the things we back at Greylock, like Rockset, the team came out of Facebook. The Chronosphere team came out of Uber. A lot of those teams on Facebook, Uber, we’ve seen the future, right? Or Soma at Docker has seen the future in terms of how people build apps and they’ve solved this problem that other folks haven’t yet but will soon. They’re just one step around the corner.

Pretty soon, the banks, maybe some of the telco you mentioned, or other companies will soon adopt this pretty quickly from containers or microservices to whatever. And those are the same customers that started early in cloud, right? Amazon, their early days were a bunch of startups, right? And then now they’re standardizing on gov clouds or financial services clouds with the likes of Goldman Sachs.

This Castles in the Cloud project that you’ve helped me on and have riffed on these ideas in the past. We’ve been tracking the big three, Amazon Azure, Google, and how they evolve over time and how oftentimes they copy each other.

But increasingly now in 2022, especially the past two years of the COVID, we’re seeing multi-cloud really be a best-practice paradigm. And multi-cloud will also include maybe private cloud as well. And HashiCorp has been, like I said earlier, this defining company in this multi-cloud conversation.

So I’d be curious, you talked to a lot of customers right now. What are you seeing about multi-cloud or cloud trends writ large? And is it going to be a multi-cloud world? Is it all going to be Amazon?

DM: Yeah. I think we all in 2012, 2013, everyone thought, “Oh yeah, Amazon got it. I’ve seen this pattern before: old world, new world, old world, private data center, VMware, new world, Amazon. Okay. Got it.”

And obviously our bet was that the steady state was multi at the time. And actually I’ve been really bullish on Azure all along because I think they’re a very dogged culture that’s going to pursue the taillights with Amazon and probably pass them at some point, just out of sheer determination. And so I think we made the view that multi was going to be the thing and that probably wouldn’t be 10. That would be a few. And that’s how it’s worked out. When you travel around, every single big company is trying to standardize on a couple, but not succeeding.

I had a conversation with the CIO a couple of weeks ago and they made me laugh. He goes, “Hey, I just finished a project of data center consolidation. We went from 18 data centers down to six. It took us two years to do.”

And I just smiled. I said, “Can I guess which ones those are?” He goes, “Sure.” I go, “Amazon, Azure, Google, Alibaba, private data centers times two.” He goes, “How did you know that?”

It’s because you look like everybody else. You have operations in China so that’s going to be on Alibaba, whether you like it or not. And whether by accident or by design, you’re going to use the other ones.

He goes, “Yeah, we just come to grips with that.”

So that’s what the world looks like. It just does. People are doing strategic deals with maybe two to try and get vendor power. But they’re not really succeeding because you have a dev team that wants to do something over here for very good reason, and then you end up there. I actually think if anything, that trend is accelerating, and I’ve been traveling around for the last quarter. Armon was in Europe, Asia and North America a couple times this quarter.

And what you see is actually that some of this stuff needs to run more in private data center, because this one’s really sensitive. So that stuff is okay to run on Amazon, and actually this one maybe needs to run on an edge pop because it’s serving an edge network.

Then you’re like, “Hold on a second. I thought there were going to be three. Now I’m seeing the big three plus Alibaba plus even Oracle instances plus some pop.” And it just speaks to that messy reality that we all live in. And I think multi-cloud just becomes the thing.

Now, as it relates to investment opportunities, company-creation opportunities: That’s awesome, right? Think about the problem that your customer has of trying to think about zero trust across those five estates. Good grief. Okay. Well it turns out that’s what we all helped them with. So I think it actually creates massive opportunities.

What initially looked like a winner-take-all game for Amazon (and then, okay, maybe just for a few of them) actually now looks like there will be a software stack that runs across all of them to solve some of these problems with consistency, and we’re certainly seeing that massively.

JC: This multi-cloud architecture, David, is fear versus greed. What I mean by fear is the fear of lock in, like the early days of Oracle. And how much is greed saying, “Hey, I want to take advantage of XYZ service on Google, ABC servers and Azure?” Is it just, “Hey, fool me once, shame on you, fool me twice shame on me – I don’t want to be locked into the NextGen Oracle”?

DM: I think it’s a bit of both. I was talking to a customer in Australia, a big bank that’s got the majority of their apps on cloud already. They basically said, “Hey, we’re going to pick Amazon and Azure and some will run on either place. We’re just trying to get them to cloud because long term, we think it’s cheaper there than we can run it ourself.”

And they’re okay with the lock in. But then there’s a certain class of applications within their estate. They’re like, “Uh-uh, this one actually needs to be built more like Zoom.” (The way Zoom is built, if you follow, it’s cloud agnostic. It doesn’t use any cloud native services from what I recall). And as a result, it can be moved around to wherever their compute fabric is. And I think people are coming to the grips, [saying], “I’m okay getting locked in because I get a lot of benefit from that. By the way, I can drive down costs. I’ll get cheaper over time that I could ever run it so I’m okay with it.”

But there are certain things which are more less sanguine about. I think that is a newer trend where people are like, “You know what? This payment app that actually is the basis of my whole thing. Maybe that one, no.” And so that’s new. I think it also just underscores my previous point around increasing heterogeneity, not less.

JC: Yeah. I used to say in the early days when I talked to developers and startups, “This is not how people use cloud. It’s not how customers use cloud in terms of an elastic workload that spreads between clouds.”

It was to your point, different workloads had different clouds that had different privacy security use cases, and you’re okay going all in one cloud, in one region for scale and costs, you’re never bursting between clouds, but there are some categories of applications and for security or privacy purposes need to be in a private cloud or for some companies like ISVs, like Zoom needs to be truly multi-cloud with the same app. But, more or less, most customers aren’t with that Zoom architecture, they don’t have one giant app that is moving around the globe. It’s really different apps on different clouds for different purposes.

DM: One insight that did surprise me (on my last current trip) was for these companies that are pretty far down the path of cloud, they’re actually starting to see cost savings year over year. As they move more of their estate into the cloud, their bill’s actually going down. You’re like, “That’s weird.” Well, it’s actually not because there’s actually truth to the thesis that the cost of storage networking on cloud is going to be cheaper than you could do it on your private data center. So they may be charging you a margin on it, but if you can get good at optimizing, “Hey, don’t over provision stuff, don’t leave stuff running that shouldn’t be running just operationally.” You can massively ratchet down your cloud spend. And I think that’s the phase of cloud to come, because it’s mature people. And if you make the bet that it’s cheaper for them to run than it is for you, it’s one-directional.

JC: Yeah. We’re seeing a category of companies (I’ve invested in a couple) around, not necessarily finOps, but reducing cloud cost and cloud spending. And I think in this economic environment right now, you will see more people focus on reducing cloud costs.

Which begs the question for me: Around cloud, how does Hashi compete or work with the big cloud providers, right? Because on the outside people say, “Oh, Amazon or Google or Azure would hate HashiCorp.” But you guys do a decent job also working with them. So I’m kind of curious how you guys thread that needle, if you will.

DM: So we actually won partner of the year from Azure through the last four years and partner of the year from Google last year. And Amazon’s a bigger partner than any of them. They just don’t have that same partner award structure. So the net is, our mission in life is actually to drive more workloads to cloud. And that’s a very, actually very unique position in the market. That’s very unlikely Snowflake or even a Confluent where, “Hey, Amazon trying to sell you a service first for data warehousing or a pub sub service.” So there’s a one to one thing they’re trying to sell. They don’t try and sell you your provisioning products. They don’t try and sell your identity brokering products. Those are just the fundamental primitive of their platforms. That’s the difference. So there is absolutely zero conflict between us.

We are like the railroad tracks to cloud for them, but allowing people to have a consistent way to provision allows them to reduce the time to get apps running on Amazon. So yeah, it’s a very unusual position but it’s a very deliberate position. And I think it took us a while to figure out that that was the right model and now we are where we are. So we definitely don’t compete with them. We’re their biggest enablers. And I think it comes down to the very practical view that your system of engagement might be running on a Kubernetes platform running on Amazon. But the database it’s connected to is probably running in your private data center. So you have a bridging problem for that real app to be built and we solve that bridging problem. Amazon cares about Amazon. VMware cares about VMware. We pay the bridge between them.

JC: I think the bridging thing is interesting, right? Because you and I have talked in the past. One of my favorite quotes is that old Jim Bartel quote, “The only two ways to make money in technology is bundling and unbundling.” And you go through this phase of bundling everything together as a PC to unbundling between the OS and the apps, bundling everything together in client server or unbundling again.

And you can argue that from 2008 to 2018, it was a bundling of compute, networking, storage databases, et cetera, into the cloud and Amazon. In the past four years, we’re seeing unbundling services, and companies like Snowflake, Confluent, Mongo, Datadog, Chronosphere, Rockset, Docker, HashiCorp, all either attacking one service a database or data warehouse or observability or a networking identity, for example.

And so now we’re seeing, I think in my opinion, an unbundling phase where you see Amazon, Azure or Google getting unbundled into independent services. And obviously something like Hashi that bridges services between data centers makes sense when you have an unbundled world.

I’d be curious, are you seeing the same thing? And if you do believe in the unbundling, where are you seeing this happening?

DM: I think 100% that’s what’s happening. I think it comes back to the heterogeneity reality for, if you’re a big company and you’re having to build things that are in multiple different places. You can’t use the pub sub mechanism on Amazon to build one app and the pub sub mechanism on Azure to build another one, it’s just way too operationally complex. So I think as reality is set in that actually I’m not going to put all my workload on Amazon. I’m going to have to deal with multiple things and my private data center, then people start stepping back and say, “What are actually the software layers that I need in the software stack?” And I’ve always contended that there are seven, there are seven core ones. There’s infrastructure, security, and networking. That’s the bottom three. Then there’s the runtime layer, the message queuing layer, and then the database, those are the core six. And then on the right hand side of that is how you monitor all and that’s your APM.

And I think there are others as well, but I think those are the ones that have been very clearly reestablished, “Hey, how do we do provisioning?” “Well, that’s Terraform, whether it’s on Amazon or Azure.” “How do I broker identity for that security contract?” “Well, that’s Vault.” “Now, how do I do monitoring?” “Well, that’s Datadog.” And so I think that heterogeneity has driven the unbundling reality because the end users just can’t deal with that much heterogeneity. Not technically. I just mean operationally. If your job is to establish a zero trust approach to your new fleet of applications, and some running on Amazon, and some are running on Azure, good grief, good luck trying to build them in different ways. You can’t, you have to step back say, “What’s my common foundation?” And then all apps are going to use that common foundation. And that is essentially a software stack that I run either on Amazon or on Azure. And it’s the same stack.

JC: Yeah. I love that seven elements and clearly that informs a lot of how we organize Castles in the Clouds and how we’ve been investing from observability like Chronosphere, databases like Rockset, elements like Docker in a compute stage. And networking insecurity is one that has to be cross- clouds. So we’re involved in a company called Cato Networks that’s basically both wide area networking across clouds and data centers, as well as secure like firewall and Kaspi across workloads. Because as you unbundle between the cloud, some things have to be a common, independent substrate like security. And so that’s obviously one we’re super bullish on as we see this unbundling of the world happen before our eyes.

DM: I think what we’re also seeing is that on the front-end stack as well. So I think as the world has gone cloud, the infrastructure stuff has gone recast, but I also think that same thing is happening on the front end stack, which used to be a very consistent stack. Now you’ve got a lot more decomposition of those elements. It’s going through that same experience. So that’s one area that’s super interesting.

I think the other one that gets super neat that we see way more than I would expect is edge. And I think edge to some degree, the way I think about it and where our customers think about it is, there’s your private data center world and then there’s the outside of your private data center world. And that outside of the private data center world, 1A is cloud, 1B is edge. Because it turns out the software stack you need to imagine a car that needs to connect to a data center. Well, it’s the same software stack as you’re running on cloud. But I got to believe there’s a lot of other specific things that edge environments (I’m not close enough to know )that are also unbundled because there’s heterogeneity of edge targets as well. So there’s probably lots of interesting things there.

JC: Yeah. Edge is one we see obviously with Cato Networks. They built their own network of ops around the globe kind of like a CloudFlare et cetera just be closer to the customer. But this edge of pushing things out leads to another theme that, I have talked about this either Federation of cloud Federation workloads across multiple class, multi GOs. And how much of that do you think is driven by a compliance of data across GOs and how much do you think is just more multi-cloud unbundling?

DM: Yeah. I just think that the practicality of deploying things where they make sense to be deployed is what’s driving it. I think Alibaba is the best example of it where if you’re going to run something in China, you have one choice and people are generally okay with that. So a lot of multinationals run stuff on Alibaba, it’s probably not the first choice, but it’s their only one. And they’re okay with that because their consumers are in China and that’s the way to how it works. So I just think it’s more practical.

That begs lots of questions around controls and how you have consistency across totally different environments, dispar environments. But it goes back to the point of this common software stack. It’s funny, I actually find myself… obviously, I totally geek out on this stuff. I just think it’s super intellectually interesting to watch these markets evolve. So you got to stop me.

But whenever I see an app like Zoom or Slack or Stripe, I can imagine how they’re built. It’s not that complicated. Or when I see my Uber driver fiddling with their app to get to that next ride, you know exactly how those are built. It’s something like Vault authenticating the identity of that endpoint, something like Console creating that encrypted connection across the internet. And it’s something like Terraform that’s automating the provisioning of the compute farm to allow it and then it’s some custom app running on top. You’re like, “Okay, cool. That’s just how these things are all built.”

And that level of consistency I think is what we’re all looking at – What is that pattern? Because I think regardless of what the underpinning compute is for that, that software stack is finding its way to standardization and that’s what’s cool for startups is – What is that market? What are those pieces that are required? And just know that the cloud vendors are not going to fight you for it. They want the compute.

JC: Okay. So that begs me to the next question. I wouldn’t be doing my job if I wasn’t picking your brain around that startup ecosystem out there – either startups out there that seem interesting, or just spaces or themes in general that you’re tracking that you think are either white spaces for yourself.

[As far as ] white spaces for startups, that as we think about Castle in the Clouds, where are the holes in the castle walls or the path or they should be following, if you will, that you would suggest to our listeners out there?

DM: I would think about how profoundly different the paradigm of cloud is relative to the old worlds, and then start looking at the existing markets in the old world and see how they’re going to get reconstituted in the cloud. I think that’s actually the right word. These markets go from old world to new world and they don’t look the same. They’re just reconstituting a slightly different form.

For example, you use firewalls for security in the old world, you use identity based controlled software in the new world, you’re going to spend the same amount of money on each, it’s just a different way. The one that we’ve been talking about goes down that thought process just is privilege access management.

And obviously we have a product in the open source community around this, but I’ll use it as an example because it just underscores how we think about it, which is the idea of privileged access management is actually a pretty well established market.

It’s the idea of how does an administrator log into a privileged machine? And they do session recording of what they’ve done and there’s compliance reasons why you do that. There are vendors in the market that do that very well today in the private data center. And that is a billion dollar spend category or probably. Well, as the world goes cloud, it’s just a different paradigm. Now you have to give temporary access to a machine that may only be alive for a minute. But the problems still exist.

So that old world, new world transition is right there for the taking. It’s like okay, well, architecturally that old way, which assumes a static IP address, target just doesn’t translate to the new world, but the spend category has to translate to the new world. So I’d look for those.

Now, for us Boundary is that product because it’s very specifically just an old world, new world transition and everybody in the platform teams that we service that you describe it to goes, “Please tomorrow.” Yes, that’s exactly my problem because you understand how different the paradigm is. So I think that’s an example.

JC: Boundary, for our listeners, is this simple, secure, remote access for your end users.

DM: Yeah. It’s [this question of] how do I SSH into that machine over there for one second when that machine only exists for 30 seconds? So this idea of old world/new world is how to look at it.

I think there are lots of those markets, things like the tokenization markets in the private data. Things like even the HSM mark, some of these really nerdy, hardcore markets that are relatively sleepy vendors in those markets because they haven’t changed a lot. Well, their world’s totally changed in the cloud world. So I would do that academic exercise. And I think you’ve done that exercise as well and you can see that Amazon services, which basically have copied that path.

JC: We’ve done that multiple times trying to find founders for startups. Oftentimes I probably get it more wrong than right Dave, but it doesn’t stop me from trying. But no, no, I would say when you have a new platform shift like the cloud, first thing happens is people try to use the old tools and the new paradigm, right?

JC: And the first question is, in the new paradigm, what breaks? And so the first thing is you fix the things that break from old tools to new tools. And then, okay, now you’re in the new paradigm, what new things can you do? So it is a two-step thing. And so there’s still a category of things that are broken. And then once you’re in the cloud, there’s a new category of things you can do differently that you did before, which is super fascinating.

We’re just beginning to see that I think because the first generation cloud was, “Let’s move what we had before into the cloud. We broke a bunch of stuff. Let’s fix it.” Now we’re seeing, “Oh now we’re in the cloud. We can build things differently.” So you guys build Boundary or Waypoint, et cetera and you’re changing. Now I can build apps differently than I did eight years ago. But I think this is the progression. You’re exactly right.

So you look old/world new world. If I were to look at all the IDC categories of spend in the current data center like, “Okay, well, which of those need to move to the cloud model if that’s where all the future apps are going to be?” You can see a one for one mapping and that’s how you get started. And then once you’ve built that, then you go, “Actually, you know what? From where I’m sitting here, you can do something totally different.”

A perfect example is what happened with Console. Console was built around this idea of, “Hey, the way you do networking in the old world is that I have to configure Cisco networking gear. In the new world, I just create a rule that says, ‘this thing talks to this thing,’ so whenever it appears connected to it, that becomes your DNS.” So basically it just speaks DNS. Whenever something wants to find another thing, Console is your DNS. That’s literally a one for one replacement.

The evolution became, “What if I wanted to run that across a wide area network and I wanted to have mutual TLS between all those services?” Well, that became the service mesh market, which people go, “Well, that service matches things pretty obvious.” Well, it wasn’t obvious – it was an evolution of Console.

In fact, even essentially a replica of that exact console idea that came out a long time after Console, but that’s an example of how you navigate, you cross over one to one and then you go, “Hold on a second. I can see something different.” And boom, an entirely new market category is created.

JC: Yeah. You can take a full circle, right? Twitter recently, one of our former VMware colleagues reminded me of a conversation I had with him saying, “Hey, the market is trying to figure out is VMware the last of the last generation companies or the first of the next generation of companies?”

And I think that was the minimal state between old world and cloud data centers, VMware and virtualization was the enabler of cloud. And I think, 13, 14 years later, we’re now the next generation where this state between how cloud 1.0, or the first of cloud, is to the second act of cloud which could be edge, it could be decentralized, it could be multiple clouds that we have generation developers and customers and users and students don’t know anything but cloud, right?

And so you and I, racked servers for the first part of our careers, and plugged in networking cards, et cetera. And now because we have a generation born in the cloud natively, what they imagine and what they expect is very different.

So, as investors, we are pretty excited that this next turn of the wheel, if you will, would be very different than the previous turn. And I think the next cache of things that we’re investing in are going to be there for the next generation of multi-billion dollar companies.

DM: Yeah. I totally agree. The generation of folks, they just think differently. In fact, I remember one of my first Hashi camp, I had no idea what they were talking about. I was genuinely confused because it’s just a different language. And I was like, I understand this stuff pretty well, but not this stuff. So to add to your point, the other point I just make, I think it’s getting easier for startups because I think there’s a logical buying center for this stuff.

I’ll draw the analog to the VMware world because it’s been on my mind a lot. The thing that happens in these infrastructure transitions is it actually requires a slight org check structure change every time it happens. And I think about what happened, pre VMware, do you want a more compute? You called up your person at HP and you waited three weeks for another machine, whatever, and it came. It then came the creation of the VI admin as a role. No, no, no, no. You just open a ticket. The VI admin will provision you a virtual machine and close the ticket because I have a pool here waiting for you. And that became the buyer for so much of VMware stuff in the end that singular role, right?

That is that entry point. And I think there’s a parallel here in cloud is the creation of these platform teams or cloud program offices. That is an essential team that goes, hold on a second. Y’all are willy-nilly adopting cloud, stop. I’m going to step back, create a common set of apertures for provisioning, monitoring, whatever it is.

And you’re all going to have to use those, regardless of whether you’re running on Amazon or on Azure or in a private data center because that’s the only way we can achieve consistency. And that is what has happened in every cloud company.

That’s what happened at HashiCorp. We have a cloud team or basically a platform team and then four product teams. Every company we engage with has a platform team and the app teams that they support. And that is your buyer. They’re the people that are deeply steeped in this domain of understanding the paradigm that’s different and that’s who you seek out if you’re a startup. You go and find that group of people who are in the cloud program office or whatever it might be and they are the ones defining the next 30 years of infrastructure.

JC: I think that’s a great place to leave it and end the conversation. This new persona of this cloud buyer, this architect has evolved and become a reality of the past four or five years. And that persona you and I have been working with in the next, five, 10 years of our career.

So David, any last advice to founders executives out there that’s starting things in the cloud and either advice on starting companies, running companies, or how to work with you in HashiCorp?

DM: Yeah, I think business-building is by definition, super fun. These are intellectually fascinating pursuits that are super interesting to pursue, particularly if you really geek out at the role that you play for these biggest companies in the world as they’re doing their things. So I would embrace the journey. There’s lots of opportunity. Last I checked, $180 billion will be spent by the big four cloud providers this year and that number is growing 30 plus percent per year. So there’s so much committed budgets out there for you to go and engage with that it is a great time to be engaging with it. And despite the macro realities and what you hear broadly, the secular tailwind is strong.

JC: Well, thank you for your time. And we’ll do another podcast on that topic, running in building companies and the leadership aspects of the journey you had in your career.

I’m Jerry Chen with Greylock partners. Thanks for listening to Greymatter.

Our mission is to help realize rare potential.